Conversation
wbclark
commented
Sep 9, 2022
wbclark
commented
A box may be configured with `multi_ansible`, which
specifies an ordered list of ansible provisioner
names, at least one of which must be the standard
name 'ansible'.
Forklift will expect to find a key corresponding
to each provisioner name within the top level box
configuration.
Each provisioner may be configured with any of
the same options supported by the base ansible
provisioner; you may also pass `reuse_vars: true`
as a shorthand to simply copy all variables from
the base 'ansible' named provisioner. For example,
example-box:
multi_ansible:
- 'bootstrap'
- 'ansible'
- 'post'
boostrap:
reuse_vars: true
config_file: ansible_bootstrap.cfg
playbook:
- 'playbooks/bootstrap.yml'
ansible:
variables:
var1: "value1"
playbook:
- 'playbooks/main.yml'
post:
variables:
var1: "value2"
playbook:
- 'user_playbooks/editor.yml'
- 'user_playbooks/dotfiles.yml'
Forklift will run the Ansible provisioners in
stages, in the order defined by `multi_ansible`.
Files named ansible_*.cfg are added to .gitignore
so that the user may define additional ansible
config files for their custom provisioner stages.
wbclark
force-pushed
the
multi_ansible
branch
from
028bb30 to
94e3a8e
Compare
There was a problem hiding this comment.
Rather than going this route, wouldn't it make sense to treat playbooks as a hash for this?
example-box:
ansible:
bootstrap:
playbook: 'playbooks/bootstrap.yml'
config_file: 'ansible_bootstrap.cfg'
reuse_vars: true
main:
playbook: 'playbooks/main.yml'
variables:
var1: "value1"
A primary concern was that everyone's existing boxes with a single ansible provisioner (actually, there is already a 2nd one, due to My thinking is that organizing the data this way was the best way to achieve that. Forklift always expects to find a portion of the yaml hash called What looks to me like the hard part of your proposal is 1. cleanly distinguishing the case of the single named |
|
I imagined it'd be similar to GH actions where triggers can be an array or a hash: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-events-to-trigger-workflows Normally I'm not a big fan of that style of programming, but in this case I think it provides a better user experience. I'll admit I haven't fully thought this through. Other things that come to mind is using some sort of inventory file. Essentially the box gains state. A whole different approach is to change things up completely and instead focus on building a base box that has all these steps set up. Then you don't need all this complex provisioning, but instead move it into the box building phase. We already do a similar thing for Katello's stable dev box using packer. |
2 participants
